Capgo에서는 3가지 값이 중요하게 계산되고 이해되어야 합니다
- 사용자
- 스토리지
- 대역폭
각각은 약간 다른 방식으로 계산됩니다
사용자
사용자가 Capacitor JS 앱을 다운로드하고 열 때마다 업데이트가 가능한지 확인하기 위해 Capgo 백엔드로 요청을 보냅니다.
앱이 이를 수행할 때, 가장 중요한 정보인 DeviceID를 포함한 작은 정보를 전송합니다.
DeviceID: 기기의 OS에 의해 정의된 고유 ID(UUID)로, 이 ID는 앱 설치별로 고유합니다.
계정이 새로운 Device ID를 받을 때마다 데이터베이스에 저장됩니다.
이전 DeviceID가 업데이트를 요청할 때마다(앱 열기), 해당 기록이 업데이트됩니다(데이터베이스의 updated_at).
이 데이터는 2곳에 저장됩니다:
update_at값이 있는 device 테이블- 오늘 활성화되고 이번 달에 활성화되지 않은 기기 수를 나타내는 일일 카운터가 있는 app_stats
플랜 제한에는 100% 신뢰할 수 있는 첫 번째 방법이 사용되고, 차트 표시에는 두 번째 방법이 사용됩니다. 홈 페이지의 계정에서 둘 다 확인할 수 있습니다:
- 차트에는 두 번째 방법
- 앱 테이블에는 첫 번째 방법
Capgo는 에뮬레이터와 개발 빌드를 사용량에 포함하지 않습니다. 시험 기간 이후에는 3% 이상을 초과할 수 없으며, 초과 시 수정할 때까지 계정이 잠깁니다.
Capgo는 또한 필터링을 수행합니다. Google PLAY에 버전을 보내도록 CI/CD가 구성된 경우, Google은 매번 20개 이상의 실제 기기에서 Capacitor 앱을 실행합니다. 새 번들의 처음 4시간 동안 Google 데이터 센터 IP가 카운트되지 않도록 차단합니다.
매월 이 데이터는 0에서 시작됩니다.
- 각 기기 요청마다 데이터베이스에서 기기를 생성하거나 업데이트
- 이번 달에 활성화되지 않은 활성 기기 수를 일일 카운터에 추가
첫 번째 방법은 900+ 사용자를 반환하고 두 번째 방법은 계정에서 200+ 사용자를 보여줍니다 플랜 제한에는 100% 신뢰할 수 있는 첫 번째 방법을 사용하고, 차트 표시에는 두 번째 방법을 사용합니다. 계정 홈 페이지에서 둘 다 확인할 수 있습니다.
스토리지
번들을 업로드할 때마다 업로드 크기만큼 이 숫자가 증가합니다.
이 데이터는 업로드 크기에만 관련되어 있으며, 앱 크기가 작을수록 플랜 내에서 더 잘 유지됩니다.
제한에 도달하거나 근접하면 CLI로 번들을 나열할 수 있습니다:
npx @capgo/cli@latest bundle list
정리할 수 있는 항목을 확인하고, 번들을 제거하면 스토리지가 확보되지만 통계는 삭제되지 않습니다.
정리할 준비가 되면 이 명령어를 사용하여 여러 번들을 제거하세요:
npx @capgo/cli@latest bundle cleanup
PS: 이는 지구를 위해서도, 여러분의 지갑을 위해서도 좋습니다 💪.
업로드의
--external을 사용하여 자체 스토리지를 사용하고 플랜에 포함시키지 않을 수 있습니다.
대역폭
이 값의 계산은 약간 더 복잡하지만, 기본 개념은 스토리지와 동일합니다.
사용자가 번들을 다운로드할 때마다 다운로드 크기만큼 이 숫자가 증가합니다.
이 데이터는 다운로드 크기에만 관련되어 있으며, Capacitor JS 앱 크기가 작을수록 플랜 내에서 더 잘 유지됩니다.
한 가지 중요한 점은 Capgo가 실제 다운로드된 크기를 볼 수 없고 번들의 크기만 볼 수 있다는 것입니다. 따라서 큰 번들이 있고 많은 사용자가 다운로드에 실패하면 빠르게 제한에 도달할 수 있습니다.
플랜 내에서 유지하는 가장 좋은 방법은 작은 번들을 사용하는 것이며, 불가능한 경우 사용자에게 다운로드 바를 표시하고 남은 다운로드 양을 알려주는 것입니다.
향후 Capgo는 한 번에 번들을 다운로드할 수 있는 기회를 더 많이 제공하도록 다운로드 시스템을 개선할 예정입니다.
